1. The Field of the Invention
The present invention generally relates to binding mechanisms used in Web Services and other distributed systems. More specifically, the present invention provides Web Services over a mail message transport using a MAPI (Messaging Application Program Interface) compliant mail application in order to support offline communications and extend the processing time of service requests without creating additional infrastructure for such message exchanges.
2. Background and Related Art
Computer systems and related technology affect many aspects of society. Indeed, the computer system's ability to process information has transformed the way we live and work. Computer systems now commonly perform a host of tasks (e.g., word processing, scheduling, database management, etc.) that prior to the advent of computer systems were performed manually. More recently, computer systems have been coupled to one another to form computer networks over which the computer systems can communicate electronically to share data. Web Services has been a driving force in advancing such communications between computer systems and is turning the way we build and use software inside-out.
Web Services let applications share data, and—more powerfully—invoke capabilities from other applications without regard to how those applications were built, what operating system or platform they run on, and what devices are used to access them. Web Services are invoked over the Internet by means of industry-standard protocols including SOAP (Simple Open Access Protocol), XML (eXtensible Markup Language), UDDI (Universal Description Discovery Integration), WSDL (Web Service Description Language), etc. Although Web Services remain independent of each other, they can loosely link themselves into a collaborating group that performs a particular task.
Often, electronic communication on a Web Service network includes a client computer system (hereafter referred to as a “client”) requesting access to a network service (e.g., Web Services) at a server computer system (hereinafter referred to as a “server,” “service,” or “Web Service”). Accordingly, the client sends a request to the service for particular access to its system resources, wherein if the client is authorized and validated, the service responds with a response message providing the desired information. Of course, other messaging patterns between client and service are available and include simple singleton messages as well as more sophisticated multi-message exchanges like, e.g., notifications, solicit-response, pub-sub patterns, polling, kick-push, queuing, and others. Further, these types of communication are governed by various requirements and capabilities defined by both the client and the service in contracts for distributed systems (e.g., Web Services).
A contract is an expression of visible aspects of a service (or client) behavior. A contract is represented by a mixture of machine-readable languages and human language. Besides the obvious opportunity for additional precision, machine-readable languages enable tooling to construct partial service implementations, automate service deployment, audit/validate messages exchanged, manage services, and enable a host of other network-related functions. Due, however, to limitations in the expressive power of machine-readable languages, human languages remain an important component of contracts—principally to describe message and message exchange pattern semantics.
Network Protocol Description Languages (e.g., WSDL) provide an overall wrapper or specification for describing contracts (e.g., Web Services Contracts) in a common or standard language. Such specifications make it easy for developers and developer tools to create and interpret contracts. These Network Protocol Description Languages (hereinafter referred to as “NPDL”) have extensive tooling suites, which in large part accounts for their popularity. Until recently, these NPDLs bound contracts to a single transport or binding mechanism, which describes how to encapsulate or format a message (e.g., SOAP envelope) and what transport to use for exchanging the message with a service (e.g., HTTP (Hyper Text Transport Protocol).
Currently, Web Service implementations use HTTP as their primary transport, partially because of its ubiquitous nature. Although HTTP has grown in popularity as a transport for Web Services, HTTP also has some widely recognized limitations. For example, HTTP is a request-response style transport, which supports synchronous style transactions. This type of message exchange pattern, however, present challenges for asynchronous communication. For instance, a Web Service client must keep-alive a connection to obtain any response from the Web Service. This makes long running transactions (e.g., a mortgage application that takes several days to process) difficult to implement using HTTP without creating a mechanism where the client constantly polls the server for updates. Such polling creates an unnecessary use of precious system resources.
Another problem with HTTP is that it is a connection based protocol. Accordingly, each endpoint in a message exchange pattern (i.e., client and service) must be alive and active to complete an HTTP request-response. In situations where this is unlikely (e.g., a client trying to connect to Web Services at some remote location), the message would be considered undeliverable and the system would fail since HTTP protocol does not support caching and storage of messages.
Still another problem with using HTTP in a Web Services environment is that the use of HTTP requires additional infrastructure. For example, to host a Web Service using HTTP requires infrastructure and setup. To support a hosted Web Service, each computing device needs to be able to accept incoming HTTP requests, which calls for installation of a Web server or equivalent functionality for each computer. This introduces new management and security issues, and as a result can be a challenge in some environments, e.g., a casual computer user or users who are otherwise not familiar with configuring Web servers.
The above limitations are already generating ideas and implementations of alternative transports that can support Web Services. Accordingly, various Web Service engines allow developers to write or extend the bindings or binding mechanisms to include a number of encapsulation and transport protocols. For example, developers can customize the transports to include one or more of the following: FTP (File Transfer Protocol), SMTP (Simple Message Transfer Protocol), TCP (Transmission Control Protocol), UDP (User Datagram Protocol), etc. Although these binding extensions allow advantageous features of other transports to be utilized they do not address the above-identified deficiencies of HTTP.
For example, when an SMTP binding is used, a standard mail message is generated wherein the body of the message includes the Web Service message, which is then transferred across the wire to the other endpoint. Although using the SMTP transport may have advantageous features over HTTP, using SMTP in this fashion still requires that each endpoint be connected via the SMTP transport. In addition, the generation and encapsulation of the Web Service message within the mail message requires addition infrastructure, again leading to management and security issues as described above.
Accordingly, there exists a need for a Web based service infrastructure that allows for extended asynchronous communications, supports offline or connectionless intervals, and utilizes existing infrastructure for exchanging messages in the Web Service environment.